Here are some odds and ends from my MIDI Generic Editor/Librarian. The most useful thing (I guess) is CPreferences. It provides a standard way to create a preferences file and read and write distinct preference information (in the form of resources, although the application doesn't see the resource information directly). The file is put into a folder called Preferences in the System Folder (Preferences is created if necessary); the file name is the name of the application, so watch out for the .<pi> for THINK C projects (I may strip this off automatically sometime soon). CPreferences seems pretty stable, although the HFS stuff was lifted blind from CInstance by Sven Axelsson; but I found that rather confusing and way too clever for what I wanted. CInstance was also buggy - thanks to Martin Minow for setting me right.
Other goodies - well, a copy of CUtility (which CPreferences needs). Nothing really world-shattering here, just some random odds and ends, although it does have an interface to the Notification Manager (needed for the MIDI stuff).
Oh, I'll also include CDiagnostic. This implements a diagnostic text window as a CDirector. However, it's not quite that straightforward, since you might want to print diagnostics in the middle of doing something graphical, and the act of printing a diagnostic would screw the graphical environment. So, CDiagnostic works in conjunction with CDiagChore, which is an idle chore which looks periodically at the diagnostic object to see if any text needs printing while awaiting events. CDiagnostic also throws away text as it fills up - not very elegantly (the last line of text moves around), but it does the job. Note also that, because CDiagnostic is a CDirector, quitting the application might nuke CDiagnostic first (if it's the top window), and screw up diagnostic messages from other windows ("I'm deactivating now", "exiting application" and so on). Complain to Greg Dow about this, not me... :-) Anyway, that's why CDiagnostic is accessed via global procedures (g_Diagnostic()) instead of method calls to a global object. Oh yes, g_Diagnostic() also takes varargs, something you don't get in methods.
While I'm here, I suppose I could throw in the MIDI Manager interface as well. Channelised echo routines, plus asynchronous System Exclusive message capture and a degree of asynchronous transmission of messages (subject to size of output buffer) - the latter is a new feature over my previous posting of the MIDI Manager code (last year sometime). There are extensive comments in CMIDI.c, since there are a lot of gotchas involved in interrupt-level driving (as you might expect). One drawback of CMIDI - transmission of large amounts of data (i.e. larger than the output buffer) causes a spin-wait. This will annoy intensely any other MIDI Manager applications (such as sequencers) which wish to look at the data and need to allocate memory at event-poll time to do so. I shall have to think of a way of decoupling the transmission routines to get around this sometime (or, Apple will have to give us pre-emptive multitasking...).
Don't be put off by the "NEW", "OVERRIDE" and "PRIVATE" keywords. They're just noise. They *should* be part of any self-respecting object language, though. "LOCAL" is just aliased to "static".
I haven't bothered including the various constants or the resource files. It's obvious stuff, folks. Besides, you don't want *everything* on a plate, do you? That would make it too easy. ("Playing strip poker with an exhibitionist somehow removes the challenge..." - Metropolitan.)
